[レポート] データファクトリーの構築：汎用ETLパイプラインユーティリティのケーススタディ – Subsurface LIVE Summer 2021

Subsurface LIVE Summer 2021

#イベントレポート

#データレイク

しんや

2021.08.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

米国時間2021年07月21日〜22日の計2日間、オンラインで開催された「Subsurface LIVE Summer 2021」では、主催となるDremio社のサービスやクラウドデータレイクに関する各種サービスやプロダクトのセッションが展開されていました。

Subsurface LIVE Summer 2021

当エントリでは、その中から「Building a Data Factory: A Generic ETL Pipeline Utility Case Study」(データファクトリーの構築：汎用ETLパイプラインユーティリティーのケーススタディ)というセッションについてレポートします。

セッション概要

セッション概要は以下の通り。

Rethinking Ingestion: CI/CD for Data Lakes - Subsurface

＜セッションタイトル＞
Building a Data Factory: A Generic ETL Pipeline Utility Case Study
(データファクトリーの構築：汎用ETLパイプラインユーティリティーのケーススタディ)

＜登壇者＞
Matt Topol - Principal Software Engineer @ FactSet Research Systems, Inc.
William Whispell - Principal Software Engineer @ FactSet

＜発表内容＞
FactSet, a leading provider of content in financial services, is focused on continuously improving our data pipeline and data fetch APIs. Most pipeline utilities like Flink and Spark require writing code to their API to define the pipeline, and to cover the breadth of content we offer, various departments have had to write custom ETL code for adding value at various parts of the content enrichment process. In order to standardize and simplify this common workflow, we decided to create a configuration file-based utility that still gives us the granular control we need, but allows encapsulation of the data movements and flows in centralized config files, reducing or eliminating the disparate custom ETL scripts. This case study will examine why we chose to leverage Golang and Apache Arrow to mix new data with our legacy sources and existing stack as we modernize our fetch code paths, and discuss other technologies we leveraged in order to do so.

(金融サービスのコンテンツを提供するリーディングカンパニーであるファクトセットは、データパイプラインとデータフェッチAPIの継続的な改善に注力しています。FlinkやSparkのようなほとんどのパイプラインユーティリティーは、パイプラインを定義するためにAPIにコードを書く必要があります。また、当社が提供する幅広いコンテンツをカバーするために、様々な部門がコンテンツエンリッチメントプロセスの様々な部分で付加価値をつけるためのカスタムETLコードを書かなければなりませんでした。この共通のワークフローを標準化、簡素化するために、設定ファイルベースのユーティリティーを作成することにしました。このユーティリティーでは、必要なきめ細かな制御が可能であると同時に、データの動きやフローを集中的な設定ファイルにカプセル化することができるため、バラバラのカスタムETLスクリプトを削減、または排除することができます。このケーススタディでは、データ取得のコードパスを近代化する際に、新しいデータをレガシーソースや既存のスタックと混合するために、GolangとApache Arrowを活用することを選択した理由を検証し、そのために活用した他のテクノロジーについても説明します。)

セッションレポート

ここからはセッションレポートとなります。それぞれのトピックに関して要点をまとめる形で紹介。

コンテキストの共有

ETFと投資信託のスクリーナーを6ヶ月で構築
複数の異なるデータソースからデータを組み合わせる
FactSet社の保持するデータの種類
- ミューチュアル・ファンド：FactSetが収集した投資信託の基本的なメタデータ
- ETFs: FactSet社が収集・管理するETFの基本的なメタデータ
- パフォーマンス。アナリティクスチームが算出したリターンデータ
- アグリゲート構成銘柄のESGデータを集計したもの
- ホールディングス：ファンドの構成銘柄に関するデータ

技術的要件

重複の削減とオーダーメイドのスクリプト
データの正規化・非正規化の容易化
独自のデータプロバイダーの仮想化
データの変換や移動の監査可能性
ポリグロット・パーシスタンス
パフォーマンス
...再利用可能なものを作ろう！

直面していた課題

技術面での制約
- EKSとEMRはコスト面で承認が必要
一般的なコストの問題
- 現在のオンプレミスのETLコストは、異なるチーム間でサイロ化されている
  - 真のコストが見えない状況
- サードパーティのソリューションを評価し、交渉する時間が限られている
  - 6ヶ月のイノベーションプロジェクト
開発者の経験と現在の状況
- 大半のチームがカスタムメイドのETLスクリプトを実行している
- 多種多様な言語で書かれたカスタムスクリプト

自作するか、既存ツールやサービスを使うか

ソリューションごとの様々なトレードオフがあり、悩ましい
- laC vs ロー/ノーコードソリューション
- 拡張性
- コネクタの制限
- 言語の制限
- コスト
今回の要件を満たすようなツールやサービスをざっと列挙するだけでも以下のようなものがあった
- Apache Kafka
- AWS DMS
- debezium
- Apache Airflow
- Azure Data Factory
- Apache Beam
- Apache Flink

Data Factory：データパイプライン

YAMLを使った設定ベースのパイプライン
- コンシューマ向けのコードレスソリューション
- エンジニアのためだけではない
並列化されたデータフローのストリーミング
- パフォーマンス
リリース時のDockerとバイナリ実行ファイル
- 使いやすさ
ニーズに応じた開発の進化
- すべてを実現しようとしない
  - 例：Sparkのようなものを置き換えるものではない
参考サービス・技術
- Golang
- Apache Arrow
- Parquet

Data Factory：コンポーネント

コネクタ
- ソース
- シンク
- トランスフォーム
トランスポート
- チャンネル
ランタイム環境
- ローカル／リモート
- Linux / Windows
フォーマット(入力／出力)
- Apache Arrow レコードバッチ
- Apache Parquet
- CSV
- etc...

Data Factory：パイプラインの構成

コードからデータセットを抽象化する
viper · pkg.go.dev
- 環境変数を使って設定を簡単に変更できる
- デフォルト値を簡単に定義できる
- コネクタは設定のサブツリーを受け取る
- 環境プレフィックスのサポート

Data Factory：Golang Concurrency(同時実行)の活用

Golangチャンネルによるコネクタ間の並列・同期転送
コネクタのシンプルなインターフェース
- コネクタを変更することなく、処理中の実装と他の実装を簡単に入れ替えられる
コネクタは同時並行で動作し、上流のパイプで次のバッチを閉じるまでブロックする
コネクタは必要に応じてステートレスまたはステートフルにすることが可能

Data Factory：エラー処理

Golang Context オブジェクトを使用して迅速に失敗する
ロギング
メッセージの受け渡し

実装上の課題

Performant Golang Parquetライブラリ
- 独自に作成したものであり、現在公式Apacheリポジトリに展開中
Dremioクライアントの読み取りタイムアウト
フォーマット機能の処理
- Apache Hudi でのParquetファイルの使用
  - Nullのあるリスト
  - 2レベルと3レベルのParquetリストのフォーマット
  - マップの論理型
- ElasticSearch
  - JSONへの変換
- ネストしたカラムタイプを持つCSV

現在の制限事項

チェックポイント機能なし
バッチ式ウィンドウモデル
バッファリングに関する基本的な調整のみ
変換の対象がバッチレコードに限定されている

今後の予定

コードのオープンソース化
コネクタの追加
- DynamoDB
- Golangのsql/dbインターフェイスをドライバで広くサポート
他のウィンドウ・モデル
設定ファイル作成・閲覧・編集のためのUI
- ビジネスニーズに応じた自動化／プラットフォーム化
ETL設定の全社的なリポジトリ
ソース及びシンクとして、Apache Arrow Flightを使用
シングルプロセスではなく分散モデルへ

まとめ

という訳で、クラウドデータレイクイベント『Subsurface LIVE Summer 2021』のセッション「Building a Data Factory: A Generic ETL Pipeline Utility Case Study」(データファクトリーの構築：汎用ETLパイプラインユーティリティーのケーススタディ)のレポートでした。

FactSet社の取り組みは、ETLを作成・管理・展開していく人々に取って立ちはだかる課題・壁であり、上手いこと解決させたいテーマでもあると言えます。今後の展開としてオープンソース化も視野に入れているようなので、新しい動きに期待したいところですね。